IBIS Macromodel Task Group

Meeting date: 23 June 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                              Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                       * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
                            * Nicholas Tzou
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                       Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad: Walter is not here today.
  - Topic was to be GND cleanup in the IBIS spec.
  - Walter did send us a draft last Friday.
  - We could discuss, but if that doesn't go far we may have a short meeting.
- Bob: I don't recall receiving the draft.  Was it private?
- Arpad: [Reviewing email distribution list]
  - It was sent to Mike LaBonte, Radek, Fangyi, Michael Mirmak, Todd and me.
  - I guess it was semi-private.
  - I would have forwarded it to the group if I had noticed.
- Arpad: Does anyone have any discussion topics that aren't on the agenda?
- Michael M: If we run out of topics, I'd like to suggest we go through the
             existing list of open BIRDs from the Open Forum list.
  - See how they're being disposed of.
  - Some are being handled through the interconnect improvements.
  - If any are pending that should be dealt with here, perhaps we should add
    them to your list.
- Arpad: That's a good suggestion.  We could do that.
  - Any other Opens for today's meeting?  [none]
--------------------------
Call for patent disclosure:

- None

-------------
Review of ARs:

- None.

- Curtis: We did not record any ARs last week.
  - One thing to mention.
  - Walter replied with two minor corrections to make sure the spirit of his
    comments were properly reflected in the minutes.
  - I sent an update with Walter's corrections to Mike LaBonte.
  - The original minutes and the modified version are both posted.
- Arpad:
  - This reminds me of a conversation Curtis and I had after the last meeting.
  - Curtis asked me if I wanted to review minutes before he posted them.
  - I replied that I had read all the minutes he had taken previously, and I
    trust his notes because they have been really good.
  - I didn't think it was necessary for me to approve every set of minutes.
  - But that raised the question, should we do it more formally and have the
    minutes approved here in this meeting, like we do in the Open Forum?
  - Michael M., would you have a suggestion on that?
- Michael M.: It probably would be the right thing to do, not just for this
              meeting but for all of the meetings.
  - It would be good to have a formal flow for this.
  - I'd like to suggest we adopt an Open Forum like minutes flow.
- Michael L.: I've seen some different practices for that.
  - Some meetings will literally read the last meeting's minutes verbatim.
  - Another practice is to have one attending member asked to review them.
- Arpad: To have a designated person to do that approval?
- Michael L: Advantage to that is one person to do it and it takes up less time.
- Arpad: I'm worried about that approach.
  - If just one person reviews them then it might not serve the intended purposes
    of preventing accidental or deliberate misstatements.
- Bob: I like the idea of putting them out for everybody.
  - Encourage people to review them and submit corrections via email.
- Michael L: Another approach is what we do in Open Forum meetings.
  - Topic is on the agenda.
  - Ask if anyone has comments or corrections on the previous meeting's minutes.
  - Then a motion to approve.
- Arpad: I agree with that.  Just like we do it in the Open Forum.
- Michael L: Gives everyone an opportunity, but doesn't take much time.
- Arpad: If no one reads the minutes then it's our own problem ;-)
  - I don't think we will run into malicious intent with any of our groups.
- Arpad: I would like to formalize this.
  - Do we have a motion to instate this extra step in our meetings?
- Michael M.: I so move.
- Michael L.: I so second.
- Arpad: Anyone opposed to reviewing minutes each meeting? [none]

-------------
New Discussion:

- Arpad: Walter sent out a draft GND document.
  - I didn't notice that it was not sent to everyone.
  - Most people here today did not see it yet.
  - I suggest we postpone this topic.
- Bob: I suggest we postpone it until next meeting, though I won't be here.
  - I don't know what has changed.
  - I reviewed draft 2, and there were substantial changes like changing
    everything to A_puref and A_gcref.
- Arpad: [sharing Walter's email]
  - Says it documents what needs to be looked at.
  - Many of the changes can go away if we say GND is not simulator reference
    node, nor is it node zero, but it's a local rail such as the model terminal
	connected to the pull down or ground rail...
  - Unfortunately, much of the buffer graphics is related to derivation
    techniques, not how buffers are used.
  - Further complicated by using a model where rail voltages are fixed to the
    data derivation voltages as opposed to the rail voltages supplied during a
    power aware simulation.
- Arpad: His email doesn't say too much about the actual changes.
- Bob: That's a controversial item, because the derivation methods are based on
       fixed voltages.
  - Without seeing what he did, that statement itself is controversial.
- Arpad: I agree that we should wait until Walter comes and we all review it.
  - Michael L., could you post it on the ATM site?
- Michael L: Should I put that up dated today?
- Arpad: Use the date the mail was sent out, since we didn't discuss it today.
  - Anything else on this topic? [none]
  
- Arpad: Walter also mentioned Fangyi could perhaps talk about IR some more.
- Fangyi: Not really, I think it's under control from the last meeting.
- Arpad: Scott McMorrow read the minutes and would like to continue the topic.
  - He couldn't make it today, but is planning on joining next Tuesday.
- Fangyi: I didn't see Scott's comments on the reflector.
- Arpad: I'm not sure if it was private or public.
  - He definitely wants to continue the discussion.
  - It's an important topic to him.
  - Bob, any comments on this?  Did you talk to him?
- Bob: No, I don't.
  - We had some private emails.
  - It's best to make this a public topic next time.
- Arpad: This topic is tabled for today.

- Arpad: We could go with Michael M.'s suggestion and open up the IBIS website
         and review the list of open BIRDs.
- Michael L: I'd compiled a spreadsheet with that info for the Open Forum.
  - We could use that.  It might be a bit out of date.
- Michael M: We now have two other BIRDS, 177 and 178.
  - BIRD 178.2 Specifying Buffer Directionality for AMI.
- Bob: A potential new one is the interconnect proposal.
- Michael M: That's not submitted yet, it will probably be at least a few weeks.
- Michael L: That is definitely active in the interconnect meeting.
  - When I created this spreadsheet the goals were:
    - List the open BIRDs.
	- Figure out when they were last actively discussed in a group.
	- Just a few notes.
	  - BIRD 128, was tabled in ATM.
      - BIRD 145, rejection had been discussed at one point.
	  - BIRD 161.1, seems like it was last discussed in interconnect in 2013.
- Michael M: BIRD 161 was mine.
  - That was tabled because it would potentially be handled as part of
    the interconnect proposal.
  - Currently interconnect does not have language addressing it.
  - So it may come back to life.
  - We can't really untable it until the interconnect proposal is done.
- Arpad: This is a good list.
- Bob: Some of these we will probably reject.
  - That was Michael's question.  What do we plan to do?
- Michael M: Quite a few will be addressed by the interconnect BIRD.
  - Those will probably be rejected once interconnect is approved.
  - Others still floating around and may need to be addressed.
- Bob: We can start at the top of the list and work down.
- Arpad: BIRD 125.1, I wrote that a long time ago.
  - Surprised interconnect was discussing it.
- Michael L: That's just mentioned because I searched through meeting minutes
  and found it.
- Arpad: Yes, it might have been mentioned but no real discussion.
- Michael M: Its content would be entirely subsumed in the interconnect BIRD?
- Arpad: Yes, and the expectation is it would be rejected at that point.
- Michael L: Should we wait for the interconnect BIRD?
  - Or entertain motions to reject?
- Arpad: I think we should wait.
  - Not sure the new interconnect BIRD will be accepted.
  - Probability is low that it won't be accepted, but simpler to wait.
- Arpad: Next one is BIRD 128.
- Michael L: Probably necessary for cooptimization.
- Bob: Probably will be approved in some form.
- Arpad: Turns the input parameter into an i/o parameter.
- Arpad: Next is BIRD 145.3.
  - That was Cadence's to allow [External Circuit] and legacy models to be
    cascaded so we could have interconnect models in the [External Circuit]
	driven by a legacy model behind them, which is currently not allowed.
  - I think the new interconnect model would probably make this irrelevant.
  - New interconnect BIRD allows us to call ISS subcircuits for interconnect.
  - This might get rejected if the new one passes.
- Bob: The issue was it also makes the multi-lingual approach more complicated.
  - Piling on complications on top of complications.
  - However, if the interconnect proposal gets too complicated and has too much
    thrown in then I may switch hats and reject it and go with this one.
- Arpad: Row 5 and Row 13 (Backchannel and Cooptimization).
  - These are either one and the same or close relatives.
  - Perhaps we should put them next to each other.
- Bob: We can cross reference them.
- Arpad: We might get some answers to this when Ambrish comes back with
         Cadence's response to Walter's presentation.
- Arpad: Next, BIRD 157 - Parameterize [Driver Schedule].
  - That was mine, based on the suggestion of Romi Mayder.
  - It is a useful BIRD for [Driver Schedule] if people are using it.
  - [Driver Schedule] currently has fixed delay values.
  - If you use the same buffer model at different frequencies, you have to
    rewrite all the delays in the hard coded format.
  - Would be nice to parameterize those for use with multiple frequencies.
  - But [Driver Schedule] is not a very hot item these days.
  - I haven't heard from Romi asking about it.
- Michael L: You might want to contact him.
  - This might be a candidate for untabling.
- Arpad: I should contact him.
  - This BIRD doesn't depend on any other BIRDs.
  - It gets rejected or approved on its own merits.
- Bob: I'm probably not in favor of it.
  - There's still no way to bring in the clock, which may be a dependency.
  - Just fixed parameters.
  - I don't like bringing in the parameter method from multi-lingual.
- Arpad: The main question now is how useful is [Driver Schedule] anyway.
  - [Driver Schedule] is basically a poor man's multi tap.
  - We can do a lot better now with AMI.
- Arpad: Next, BIRD 158.3 - AMI Touchstone Analog Models
  - That was SiSoft's BIRD to provide a totally LTI analog buffer model using
    touchstone.
  - Scott might be interested in this given the recent discussions.
- Bob: Yes, we might resurrect it.
  - Scott was opposed to it at first.
  - It is a fixed topology.  That was the issue.
- Arpad: I tend to have second thoughts about it, too.
  - Fixed topology, lacks flexibility.
  - Also goes against the grain of power integrity simulations since power and
    ground referencing is somewhat limited.
  - Might be useful for LTI requirements of AMI, but not for non-LTI analog
    model simulations.
  - Could stand on its own.
- Arpad: Next, BIRD 161.1 - Supporting Incomplete and Buffer-only [Component]
                            Descriptions.
- Michael L: Is that in the interconnect proposal?
- Michael M: It is not.
  - There is some handling of package and interconnect descriptions that are
    incomplete, and there are some implied interactions.
  - But this BIRD was intended to identify to the user and tool the intent of
    the model author to model the entire component or not.
  - This BIRD can wait until after the interconnect BIRD is complete.
- Michael L: Does the interconnect group think this is in their domain?
- Bob: I don't think it's in the interconnect domain.
  - My concern is that it has gotten complicated with subparameters.
  - All you want to convey is "yes" or "no" is the model a complete model?
- Michael L: Like the touchstone analog buffer model BIRD, this one has a lot of
             models out there doing this already.
- Bob: Yes, there's nothing that prevents you from creating a 1 Pin [Component].
- Michael L: Should this be in ATM?
- Bob: I don't know when to bring it up.
  - If we want to add a new informational subparameter in 7.0, so be it.
  - But we support legacy IBIS without them, and there's nothing that prevents
    us from issuing partial models.
- Arpad - This is vaguely related to recent discussion about the completeness of
          [Pin] and [Pin Number] lists between the package and the IBIS file.
  - This is also dealing with incomplete models.
- Michael M: You're right.
  - The key difference is there we have an identified [Pin] list we can compare
    against the identified interconnect models.
  - That's separate from this informational keyword identifying to the user
    that the model you're working with is not intended to describe the entire
	[Component].
  - Useful because there's no automated way to otherwise know you have gotten
    everything.
- Bob: That's the valid point.
  - One application might be a large device and you only model one quadrant.
- Michael M: I think this can stay tabled until interconnect is done.
- Michael L: I'd just feel better if we kept a list of tabled topics like
             Arpad has on his agenda.
  - I don't see BIRD 161 on any of those lists.
- Arpad: That tabled list wasn't purposeful on my part.
  - I just put the topics on the agenda, and then once tabled they move down to
    the tabled section.
  - I vaguely remember discussing BIRD 161 once in ATM.
  - I'm not sure why it didn't make it to my tabled list.
- Michael M: Do we need to maintain an overall tabled list in this meeting?
  - I'm willing to make that motion.
- Bob: I make a motion that we complete the tabled list with the BIRDs under
       consideration at this point.
- Arpad: The motion is to complete my tabled BIRD list with all these BIRDs.
  - So we have a complete list?
- Bob: Yes.
- Arpad: Do we have a second?
- Michael M: Second.
- Arpad: Anyone opposed [none].
  - Michael L., please send me the spreadsheet.

- Arpad: BIRDs 163 and 164 (also 125) all competing with interconnect.
  - These are all addressing the same feature set.
  - I would expect one winner.  Is that correct?
- Bob: Interconnect would be the alternative approach.
  - The last three are multi-lingual approaches to the same problem.
- Arpad: BIRDs 163 and 164 are using [External Circuit] for packaging or on
         die interconnect.
- Bob: It has architectural implications.
  -  [External Circuit] is that on die or outside the die?
- Arpad: Yes, that's the debate.
- Bob: Depends on interconnect whether we resurrect them or not.
- Arpad: Expect these might be rejected then since interconnect is a superset.
  - Possibility of rejection is high.
- Bob: Because we don't want to do the same thing two different ways.
- Michael L: That comment applies to 125, 163, 164?
- Bob/Arpad: Yes.
- Arpad: Next, BIRD 165 - Parameter passing improvements.
  - I wrote this.
  - Currently parameter passing is done on the [External Circuit] or
   [External Model] keyword level.
  - But the [Circuit Call] is actually what instantiates the external
    circuits.
  - Having the parameter passing on the [External Circuit] level means
    every single instance gets the same value.
  - This BIRD is independent.
  - Its fate might depend on how much effort we want to put into continuing
    the use of these [External Model] and [External Circuit] keywords.
- Arpad: Next, BIRD 166 - Redriver Flow.
  - Walter and Fangyi's solution.
  - Independent BIRD, will need to be discussed on its own.
- Fangyi: Last time we decided to table it.
  - Walter and I will have more discussions.
- Arpad: Yes, it can become active on its own at any time.
- Arpad: I think we are done with this list.
  - Thanks for that suggested discussion.
- Arpad: What was the intent of my "complete" list of tabled topics?
  - Just the ones that aren't being discussed elsewhere, for example in the
    interconnect meetings?
- Arpad/Bob/Michael M./Michael L.: - [decided Arpad should list them all].
- Arpad: I'll keep a complete list in the agenda.
  - Any other questions before we hang up?
  - Next week I expect to discuss GND.
  - If Scott can make it we will also discuss the LTI modeling for AMI.
  - Thank you all for joining.

AR: Mike LaBonte to post Walter's draft GND document.
AR: Mike LaBonte to send his BIRD spreadsheet to Arpad.  
AR: Arpad to add review of minutes to the ATM agenda each week.
AR: Arpad to add all BIRDs from the spreadsheet to the ATM agenda's tabled list.
AR: Arpad to contact Romi Mayder regarding BIRD 157.

-------------
Next meeting: 30 June 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
